1. Technical Field
This application relates to the field of logging messages, and more particularly to the field of providing and combining different techniques for logging messages.
2. Description of Related Art
Message logging in software may be used for a number of purposes, including software development. A developer may insert in source code calls to a logging function to cause an appropriate message to be saved in a log file (or possibly displayed on a screen), thus facilitating error detection and the monitoring of intermediate values of variables. For example, the developer may test if an index variable exceeds the number of elements in a table and may insert a call to log a message indicating the condition. The code may be something like:
If (index_variable>NUMELEMENTS) then                call log routine to indicate index out-of-bounds condition        
In some cases, message logging may be used in production code provided to end users. If the user experiences a problem with the code, it may be possible to examine the log file to determine, for example, whether the problem is due to code errors or to a user mistake. Of course, for production code, the number and type of messages that are logged may be different than that used for code under development.
Software may be developed in a standardized manner to be placed on a processing appliance, such as the Common Appliance Platform (CAP) provided by EMC Corporation of Hopkinton, Mass. The CAP provides common access and login, common remote update, patch, and rollback and common administration, configuration, and remote service. The CAP may allow the user to save money while possibly having a better user experience.
For software developed for CAP, it is useful to have a standardized logging mechanism where different logging text messages may be represented using tokens (values) that are mapped one-for-one to each message. For example, a token value of seventeen may correspond to a message “Index out of bounds” while a token value of thirty corresponds to a message “Divide by zero error”. Using tokens to represent messages has many advantages, including facilitating translation and being able to test the message tokens and perform particular actions based thereon. It may be much more straight-forward to test if a message token value equals seventeen than it might be to examine a text string to determine if it says “index out of bounds”, especially when considering all the possible variations (e.g., capitals, spaces, punctuation, hyphens or no hyphens, etc.). Furthermore, in the case of the CAP, standardization of the logging and using tokens allows combination and comparison of logging messages across different applications. Thus, there are many reasons to provide in the source code calls to logging routines using tokens rather than actual in-line text messages.
On the other hand, it may be easier for a developer to use in-line text messages in the source code when adding calls logging functions. For example, instead of needing to know or look up the token value for a divide by zero error, the developer may prefer to simply insert the text message directly in-line as a parameter to the logging function call. However, doing this negates the benefits of using tokens, discussed above.
Accordingly, it is desirable to provide a logging system that allows developers to insert logging text messages directly into calls to logging functions while still providing benefits associated with using tokens for calling log functions.